Buffers are widely used in many types of packet type networking equipment; for example routers, Base Stations (BSs), wireless Access Points (APs), Packet Data Serving Nodes (PDSNs), Serving General Packet Radio Services (GPRS) Support Nodes (SGSNs), Gateway GPRS Serving Nodes (GGSNs), etc. In recent years, the proper setting of buffer sizes in routers/switches (or any network nodes that process Internet Protocol (IP) packets) utilized in IP Networks in order to meet the performance requirements of IP-based applications has impacted network performance.
Traditional Transmission Control Protocol/Internet Protocol (TCP/IP) communications have been primarily used for applications such as file transfer, emails, web browsing, etc. While the TCP protocol employs a built-in retransmission mechanism that provides reliable, in-order delivery of data, making it suitable for applications capable of tolerating network delays, these same applications are not as accommodating in regards to packet loss. As a result, the performance objective of these TCP-based applications and corresponding network services primarily is to minimize packet loss, as opposed to packet delay.
The exponential growth of the Internet has prompted the introduction of new interactive real-time applications using packet transport, such as Voice over IP (VoIP) and packet-based Video Telephony (VT). However, these real-time applications are very sensitive to packet delay and delay variation (jitter), while more tolerant of packet loss. Therefore, these interactive real-time applications have performance requirements that are contrary to those discussed earlier regarding TCP. As a result, the performance objective of real-time applications is to minimize end-to-end packet delays in the network. For example, in VoIP, any end-to-end packet delays smaller than 150 milliseconds (msec) are not perceived by a human listener; delays between 150 and 350 msec can be acceptable; but delays exceeding 350 msec will seriously impair the interactivity in voice conversation. Although the underlying transport still uses IP packets, these delay-sensitive applications typically use User Datagram Protocol (UDP) instead of TCP because UDP does not retransmit any lost packets (like in TCP). Furthermore, the retransmission of packets results in a long round-trip delay which is not useful for delay sensitive real-time applications.
A router is a computing device that connects at least two networks or devices together. Routers have software and hardware components that are typically tailored to the tasks of routing and forwarding packet-based data in a computer network. Routers use protocols such as Internet Control Message Protocol (ICMP) to communicate with each other, data headers, routing tables and routing protocols to determine the best path for forwarding the packets of data between any two hosts. Routers typically contain a specialized operating system, Random Access Memory (RAM), Non-Volatile RAM (NVRAM), flash memory, and one or more processors. However, with the proper software, even commodity PCs can act as routers. Routers also contain buffers in order to temporarily store data that the router is not yet ready to process.
A buffer is a temporary location to store or group information in hardware or software. Buffers are used whenever data is received in sizes or at rates that may be different than the ideal size or rate for the hardware or software that utilizes the buffer. For example, a 64-bit processor on a 16-bit bus may contain a buffer to hold 16-bit requests until they equal 64-bits. Another exemplary use of buffers is to prevent a hardware device from becoming overloaded or saturated with information. In this example, a buffer is used in order to temporarily store data until the device or program is ready to receive the data, as opposed to unloading the data onto the unready device. Buffers should be optimized in size in order to work efficiently. However, sometimes buffers, just like any other storage device, can become full of too much data. For example, if a buffer receives too much data, and cannot process the data fast enough, then some of the received data may be dropped by the buffer. Similarly, the buffers contained in routers may also become full as one of the networks the router is connected to becomes congested. As a result, the router and buffer may drop packets of data.
In order to reduce the probability of dropping packets of data, larger buffers at each router may be employed and/or multiple buffers at each router may be employed. While the larger buffers will certainly minimize the packet loss in the network in the case of traffic congestion, as the buffers fill up the delays encountered by each packet would increase dramatically. On the other hand, if the buffers are too small, while the delay may be reduced, the packets will be dropped too frequently. Hence, there is a tradeoff between a buffer that is small enough to meet the packet delay requirements and, at the same time, large enough to have a high throughput (low packet loss).
In today's IP networks, there are three primary methods for setting buffer sizes. However, these methods were developed in order to minimize the packet loss for TCP-based large file transfer applications. As discussed earlier, TCP is not suitable for interactive delay-sensitive applications, e.g. real-time. The three methods are: Bitrate-Delay Product (BDP), Over-Square Root and Connection Proportion Allocation.
The BPD method sets the buffer size to be equal to the product of the Bitrate of the Outgoing Link and the Round-Trip Delay as shown in equation (1) below; where Bitrate is the Link Speed, and the Round-Trip Delay is the Round-Trip-Time (RTT) of a TCP connection.Buffer Size=Link Speed×RTT  (1)
However, the BPD method considers only one TCP connection, and not multiple TCP connections. For example, if the link speed is 100 megabits per second (Mbps) and the RTT for a TCP connection is 500 msec, then the buffer size is (100 Mbps)×(500 msec)=50 megabits (MB). In estimating the RTT of a TCP connection, the BPD utilizes a random TCP connection and uses its RTT for computing the buffer size.
The Over-Square Root Method uses several competing TCP connections in computing the buffer size. Thus, the buffer size should be set to be equal to the BDP of the outgoing link divided by the square root of the number of TCP connections as shown in equation (2) below. The rationale is based on the observation that some TCP connections might lose no packets during an overflow of the buffer. Therefore, it corrects the buffer size requirement of BPD by dividing the square root of the number of TCP connections.Buffer Size=BDP/(# of TCP Connections)1/2  (2)
The Connection Proportional Allocation Method sets the buffer size to be proportional to the number of TCP connections. The rationale is that the buffer must accommodate relatively few packets from each connection in order to avoid a high packet drop rate, and that TCP works well if the network stores roughly six packets per active TCP connection.
In reviewing the above three methods, all three methods are adapted for TCP-based applications and do not work well in today's IP networks, in particular for interactive real-time applications such as VoIP and video telephony based on UDP. Furthermore, there are some serious issues with these existing methods. First, since there are many TCP connections passing through the router it is not clear which TCP connection should be used for the BPD computation. Additionally, each TCP connection has its own round-trip delay, but the BPD computation is based on only one TCP connection. Thus, the buffer size is dependent upon the random selection of a single TCP connection because BPD is directly proportional to the one round-trip delay of TCP.
Second, the IP router does not know the round-trip delays for each TCP connection. Thus, these methods depend on outside signaling of other routers and end systems to estimate the RTT of the TCP connection.
Third, all three methods are designed for long, large file transfers over a TCP connection; hence, buffer sizes are overestimated and are not suitable for real-time applications based on UDP. Therefore, it is not feasible to implement the existing methods for real-time IP applications not using TCP, as these methods require round-trip delays of TCP connections that are not available at the IP router.
Fourth, the last two methods are inconsistent with each other in attempting to accommodate multiple TCP connections in buffer size estimation.
Hence a need exists for determining the optimal buffer size in an IP network particularly as can be adapted for real-time applications or the like that are sensitive to latency.